Terminals of this type may, in particular, be telephones using the wireless application protocol (WAP), office computers, portable computers or personal digital assistants (PDA), sharing the common characteristic of being connected to a digital data network which, in many practical cases, is a network operating according to the IP protocol (“Internet protocol”), in particular the Internet.
Various applications can be installed in these terminals. Among these applications, a distinction is frequently made according to various criteria such as their origin, the degree of confidence assigned to them by an administrator, etc., resulting in different capacities for certain applications in relation to others.
For example, in systems operating under the “Unix” operating system, the execution rights of applications in the “setuid root” class are the maximum rights, at administrator level, whereas the execution rights of other applications are simply the rights of the user launching the application. In another example involving Web browsers which comprise a virtual Java machine, the applications, referred to as “applets”, downloaded from a given website, are limited in terms of their capacities to access the network, i.e. they can only transmit HTTP (“Hypertext transfer protocol”) requests to this website.
Some of these execution rights of the applications are purely local. This is the case, for example, with the right to take control of the screen of a terminal, and the right to know all the keys pressed on the terminal keyboard, even for other applications.
However, other execution rights can be observed remotely. This is the case, for example, with the right to transmit any IP packets, including IP packets which do not comply with the most common transport protocol formats, i.e. TCP (“transmission control protocol”) or UDP (“user datagram protocol”). In Unix systems, this right is not granted to applications which are not in the “setuid root” class. By using this difference in the capacity to transmit requests, a remote observer such as a server can determine that a given packet has been transmitted by an application in the “setuid root” class: if it observes that this packet does not comply with the TCP or UDP format, it must necessarily be an application in the “setuid root” class; if not, it may involve an application without special rights.
In the case of applets in browsers on personal computers, the capacities to send HTTP requests are limited to the single site from which the applet was downloaded. For each received HTTP request, a Web server may therefore infer that it originates either from an applet present on the site or from a different application (for example the browser). However, in any case, the requests received by a Web server do not originate from “foreign” applets present on other sites.
Interest is focused here on the problem of knowing how a server may, in a secure manner, capture the consent of the user with regard to a given question. The question to be posed to the user must be presented to the user via an application on the user's terminal. The application captures the consent (or refusal) of the user, then transmits a corresponding indication to the server.
The server therefore receives messages on the network and interprets them as the consent (or refusal) of the user. To do this, it must assume that the application has in fact presented the question to the user and has captured the user's consent in all honesty. The server therefore assumes that the application is not a “Trojan horse” which has, for example, presented a different question to the user, or has simply not presented the question to the user, but simulates the user's consent. To protect the user against any programs of the “Trojan horse” type, this assumption of confidence must be assured.
Several means exist for reasonably satisfying this assumption of confidence in the application.
Some applications are recognized as “confidence” applications. An application of this type is, for example, the WAP browser. A server may have confidence in a WAP browser for it to display a page posing a question to the user and wait for the user to enter his response.
In the case of a “closed” terminal (e.g. a. Minitel), the applications presented on the terminal are known and cannot be changed during the lifetime of the terminal. All these applications are recognized as “confidence” applications.
The openness of a terminal refers to the facility offered to the user to install, and often download, new applications which are intended to be run by the terminal itself. Examples of “open” terminals which integrate this facility are:                application-downloading telephones, for example of the Java MIDP type (“Mobile Information Device Profile”, Sun Microsystems, Inc.);        browsers with scripting functionalities, for example of the WMLScript type (see “WAP WMLScript Language Specification”, version 1.1, WAP Forum, November 2001) or ECMAScript (also referred to as JavaScript, see “ECMAScript Language Specification”, Standard ECMA-262, third edition, December 1999), or browsers which accept applets;        most of the PDAs operating under operating systems such as PalmOS, WindowsCE, Symbian, etc.;        office or portable computers.        
“Semi-open” terminals are open terminals in which certain functionalities are not directly accessible to the applications installed by the user or downloaded. For example, in a terminal whose only “openness” is ECMAScript, downloaded applications cannot access all the functionalities of the network (for example, transmission of any given IP packets). These functionalities may be accessible in an indirect and controlled manner. For example, an ECMAScript function may order the loading of a page via HTTP, which entails using the network, but in a controlled manner.
In “semi-open” terminals, there is coexistence:                of applications regarded as “confidence” applications, for example because they have been factory-installed by the terminal manufacturer, or because of the guarantee obtained by means such as the electronic signature of the application, etc.        and of other applications which may be installed on the terminal by the user himself, at his own discretion, but which do not access the same rights as the confidence applications.        
On the other hand, “fully open” terminals are open terminals in which all functionalities are accessible to the downloaded applications. The notion of openness of a terminal depends largely on the context in which it occurs. For example, different layers of the OSI model (link/network/session/transport/etc.) may have different degrees of openness.
Interest is focused here on the functionalities which can be observed remotely from a server, i.e. network functionalities. In this context, the “semi-open” character of a terminal generally implies that execution rights which can be observed remotely and which are accessible to confidence applications are not accessible to non-confidence applications (for example the right to transmit requests other than HTTP on an IP network). This enables a server to distinguish, from among the requests received by it, those which originate from confidence applications and those which originate from other applications.
“Applets” which the user installs at his own discretion do not necessarily afford the confidence to access any given server. However, the restriction of the requests of each applet to the site from which it was downloaded enables a website to maintain control over the applets which can transmit requests to it. It is therefore reasonable for the server to assume that the applications presenting questions to the user are not Trojan horses. These applications are therefore “confidence” applications, but for one website only.
In open terminals, the possibility that a program may behave in a deceptive manner vis-à-vis the user (Trojan horse) must be taken into account. Thus, nothing can guarantee to a server that a request actually originates from the user and not from a program which has simulated the user's consent in the network. This risk undermines the confidence which the server may have in the data which it receives from a client. The assumption that the requests addressed to the server reflect the actions of the user is not reasonable if a Trojan horse has the facility to send them instead of the user.
The conventional response to the Trojan horse risk is to limit the capacities of the non-confidence applications.
The limitation of the transmission of frames from semi-open terminals is normally imposed in an extremely strict manner. Only confidence applications are authorized to transmit certain frames. This distinction is used so that the server does not accept, as representative of the user's consent, frames transmitted by non-confidence applications which may betray the user.
It therefore becomes impossible for an non-confidence application to transmit frames to a server. It is, in particular, impossible for this application to prove the user's consent to this server. For example, it is impossible for a non-confidence application to propose to the user to make a payment using an electronic commerce server.
For an “applet”, which is restricted to being able to transmit requests only to the website from which it was downloaded, confidence is conferred upon this server only. It is therefore possible for this applet to capture the user's consent and to transmit the result to the website from which it was downloaded. It is therefore—reasonably—assumed that the server has never proposed to download “Trojan horse” type applications.
Cryptography-based systems exist to generate electronic signatures. An example is described in the specification “WAP WMLScript Crypto Library”, WAP Forum, June 2001. These systems can be used to capture the user's consent, wherein they assume that the system is semi-open, i.e. in this case that the functions for accessing cryptographic keys are not directly available to non-confidence applications. Access to cryptographic keys is managed by a specific software component, which will be referred to as the “electronic signature component”, and which is responsible for capturing the user's consent on behalf of the application. This component itself performs the following concatenation of operations on behalf of the non-confidence applications:                display the text to be signed on-screen;        wait for confirmation from the user        if confirmation is received, use the cryptographic keys of the user to sign the displayed text;        if not, do not sign the displayed text.        
This therefore allows non-confidence applications to obtain an electronic signature of the user's consent via the electronic signature component. This method allows the server to obtain the user's consent concerning any given text.
It must also be assumed that the terminal is not fully open. If it were possible for a non-confidence application to gain direct access to cryptographic functions, it would not be possible to know whether the call for cryptographic functions was actually preceded by a display of the entire text to be signed or whether the terminal actually waited for the user's consent before proceeding with the signature.
Furthermore, this method implements cryptographic techniques which may prove costly in terms of execution time, the size of messages exchanged on the network and power consumption (an important consideration in the case of portable terminals). Moreover, legislation governing cryptographic techniques may possibly restrict the facility to make use of this method.
It is therefore desirable to provide a behavior which is more or less equivalent in terms of openness to non-confidence applications, but without using cryptography.